The present invention generally relates to web services. More particularly, the present invention relates to supporting requests for web services by composing additional supporting requests for web services.
Different approaches have been introduced to specify guidelines for interoperability of services and service enablers. Such approaches have included Web Services, java beans, portlets, CORBA/IIOP (Internet Inter-Orb Protocol), and others. These approaches require that developers specifically provide particular function calls for services and service enablers. Further, these approaches require the developers to create and support virtually all of the additional services (“support functions”) for such services. Because of this, there is often little incentive for developers to develop supporting functions that could be used by other developers. Accordingly, few, if any, situations are envisioned where services and service enablers from independently developed providers can be used together at run-time.
Current approaches to interoperability include Parlay, and Web Service technologies including WSFL (Web Service Flow Language), WSXL (Web Service Experience Language), UDDI (Universal Description Discovery and Integration), OASIS WS inspection, OASIS WS-Security, WS-Provisioning, SLA (service level agreements), Liberty from the Liberty Alliance Project, and others. These approaches specify guidelines for supporting functions, however they do not specify any mechanism on how supporting functions can systematically be used or enforced. More particularly, the inventor of the present invention has determined that these services do not contemplate independent service function composition, combination, aggregation, or coordination in any way that would allow a service provider to control and manage efficiently the way that it exposes its enablers or services to other parties in automatable ways, where the requestor can determine the conditions that it must satisfy to access and use the enabler or the services and can satisfy them. Further, the existing services do not contemplate the service provider validating that these conditions as well as any additional conditions internally imposed and not exposed to the requestor, have been satisfied. The inventor has determined that typically, such conditions amount to specifying what are the supporting functions that must be called, for example for authentication, authorization, charging, or logging—only authentication is exposed and the conditions presented to the requestor allow the requester to provide the appropriate credential (e.g. user ID and password or digital certificate). Further it allows the requester to provide the credentials in the right format (e.g. digital certificate, compression). These conditions will be referred to herein as execution policies.
As an example, the Parlay framework specifies a centralized framework for discovering and supporting service enablers. Upon authentication of a requestor, a service enabler is instantiated and made available to the requester. However, the framework was developed prior to and independently from web services and therefore it does not, for example, cater for providing the Parlay framework functionality to generic web services. The Parlay framework is fundamentally a session-based approach where services are instantiated upon request and then protected by hiding its address for the duration of the instantiation. This, and a Corba architecture, are not a recommended solution for distributed deployment across different domains. Further, Parlay requires skilled developers to use an IIOP framework or a CORBA architecture (even when on top of HTTP or using SOAP) and develop appropriate interfaces for each service enabler or service. Composing such interfaces is not simple, thus the adoption of this approach for determining the availability and the enforceability of supporting functions is limited.
Additionally, the Parlay framework does not appear conducive to distribute deployments over a network, such as the public internet, based on Web Services. More specifically, the Parlay Web Services Framework (authentication, authorization and SLA (Service Level Agreement)) is based upon instantiation of known services, and not upon discovery and use of new enablers or services.
In light of the above, what is desired is a new common framework without the drawbacks described above.